NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/669

Text File | 1996-08-05 | 7.8 KB | 200 lines

Newsgroups: comp.sys.amiga.programmer
Path: techfak.uni-bielefeld.de!isthesin
From: [e-mail] (Stephan Thesing)
Subject: Re: PPC compilers
Message-ID: <[e-mail]>
Sender: [e-mail] (Stephan Thesing)
Date: Wed, 10 Jan 1996 11:31:56 GMT
References: <[e-mail]> <[e-mail]> <4c9i2l$[e-mail]> <4ck47h$[e-mail]> <[e-mail]> <4cokkg$[e-mail]> <[e-mail]> <4cqrti$[e-mail]> <[e-mail]>
Nntp-Posting-Host: moos.techfak.uni-bielefeld.de
Organization: Universitaet Bielefeld, Technische Fakultaet.
X-Newsreader: xrn 8.01

In article <[e-mail]>, [e-mail] (Jason S Birch) writes:
|> [e-mail] (Stephan Schaem) writes:
|>
|> > polymorphism?
|>
|> > int a,b,c;
|>
|> > ...
|> > a = b /c;
|>         ^
|> > a *= result;
|>     ^
|> The "/" and "*" are polymorphic - you can use them in any mathematical
|> expression, without caring whether the left and right sides are chars,
|> shorts, longs, floats, doubles, or any equivalent type. If they were
|> not polymorphic, you might have, for example:
|> a int= b int/ c;
|> a int*= result;
|>
|> This is essentially what you have in assembler. Note that with C++,
|> you can overload "+", "-", "*", "/", "=", etc, to work with any custom
|> classes as well, so you could have, for example:
|>
|> vector a,b,c;
|> real r;
|> ...
|> a = b + c;
|> r = a * b;
|> cout << "Values are: " << a << ", " << r << ".\n";
|>
|> and have, say:
|>
|> Values are: [3,7,3], 67.
|>
|> as the output.
|>
|> > struct.float = a;
|>
|> This is polymorphism of "=", but it's also taking advantage of the
|> fact that C can convert an integer into a float.
|>

[Somehow out of topic, but maybe interesting:]

In fact, this is mostly called 'ad hoc polymorphism'.
Real polymorphism is (at least in functional languages) something like this:

   id x = x
A function id, the identity on everything.
it's type is * -> *, saying it can take an argument of arbitrary type and
gives something of the same type as result, e.g.
id 'c' = 'c'
id 5635635 = 5635635
id [1,2,3,4,5] = [1,2,3,4,5], etc.pp

This is something different from ad-hoc-polymorphism, since there, for each
different argument type you have in fact a different operator, e.g.
1 + 2       + has type int x int -> int
1.3 + 4.5   + has type float x float -> float
The same goes for overloading in C++






|> > I dunno , I just find it puzzling to declar variable without giving
|> > a care of what its usage will be. You programing practice is VERY unwise...
|>
|> Your misunderstanding is that you think he means he has no idea of
|> what types each variable is, whereas what he's saying is he need have
|> no idea of how each type is actually implemented on a particular
|> machine/OS - all he has to do is know how those types are defined to
|> behave under ANSI C. In fact, if you want to write portable code, you
|> have to restrict your knowledge of behaviour of the types to that
|> which is guaranteed under ANSI C. Taking advantage of any other
|> information you might have (eg. endian-ness, number of bits) limits
|> your portability.
|>

Right, this is a difference between ASM and HLL:
ASM is defined in operational terms, where everything is fixed (word size, bit order..)
HLL are defined by the 'meaning' of a program, abstracting away from real
hardware, just by looking at concepts as store, values, etc.
How this meaning (semantics) is IMPLEMENTED on a real hardware is
subject to the programmer, as long as he stays in the framework of the semantics.
(e.g. he may choose to implement integers as BCD numbers. this is ok, as long as
the behaviour of his implementation is the same as that defined by the semantics)


|> >: I know better than to declare a value as unsigned long when I'm
|> >: going to assign a clock_t to it.  And if I did, I'd lose the
|> >: fractional part of a floating-point clock_t, not the upper 32 bits.
|>
|> > You said yourself after peeking at the .h that clock_t was a ulong.
|> > But you know better then not using a ulong... ? Should I assume
|> > you alway use the largest data type available,double ? (What a waist)
|>
|> No, you should use clock_t! If you want a variable to use in functions
|> that expect a clock_t, you declare it thus:
|>
|> clock_t Stephens_var;
|>
|> You do *not* declare it as:
|>
|> ulong Stephens_var;
|>
|> even if you *know* that on your particular implementation, that's what
|> it really is, because that restricts your portability.
|>
|> > And you mean you would loose the fractional part of clock_t if you
|> > used ulong , not the upper 32bits? This make absolutly no sense since
|> > we are talking about interger types.(BTW copy 0x00000001 into a 2byte int,
|> > you will loose the upper 16bit... )
|>
|> You lose nothing if you declare it as clock_t.
|>
|> > If the header file was programmed correctly it would not use ANSI data
|> > type directly....
|>
|> Why not? You should just know better than to look at it and take
|> advantage of that information.
|>
|> Incidentally, when I create a custom data type I want to keep private,
|> I provide a public header file similar to:
|>
|> typedef void *MyDataType;
|>
|> MyDataType *MDT_Create(...);
|> void MDT_Dispose(MyDataType *);
|>
|> and inside the private header file, I actually define what MyDataType
|> is. This way, no-one can "accidentally" use the internal definition,
|> and I am free to change it at will, without having to worry about
|> those who *don't* know better than to look at it and take advantage of
|> the information.

This is why C++ was invented ;-)

|>
|> > The way you get optimal speed is optimizing the optimal algorithim.
|> > If you stop at the algorithm you loose... Optimizing at this stage
|> > will give an exponential result on the work you done on the algorithm.
|> > And usually this stage is done in assembler.
|>
|> The problem is, do you want portable code? If yes, then you should be
|> aware that what might be optimal for one particular CPU using one
|> particular compiler is not necessarily the same for another. For
|> example, scanning through an array and adding the contents using array
|> dereferencing and a moving pointer: On an 040 Amiga, the latter was
|> faster; using gcc on a Sun, both produced the same assembler code; and
|> using Metrowerks on a PowerMac, the former was actually quicker
|> because the pointer method used post-incrementing (ie. sum += *ptr++)
|> and the compiler wasn't smart enough to realize it didn't need to
|> store the pre-incremented value and used an extra register to store
|> it. The moral? Don't make assumptions about what is an optimization,
|> and what isn't, unless you test it on every combination you plan to
|> run it on.
|>

One may argue that portability is not necessary, if one knows on which
machine the program will be run.
This is true, but unfortunately, as the Amiga line has shown, we can not
be sure, if the next machine has the same CPU (it may even have a CPU from a different
family, as the PPC discussion shows..).
But surely you want your program to run on the new machine as well, at least
if you plan to make it publically available.
So you have to take into account the portability issue as well. HLL
programmers can (but need not) write portable code more easily. And they
have the advantage that the compiler will optimise their program on a new machine
as well as on the old one.


Bye...
    Stephan

|> > Stephan
|>
[sig deleted]

--
===============================================
=             Stephan Thesing                 =
=        AG Praktische Informatik             =
=          Technische Fakult"at               =
=         Universit"at Bielefeld              =
===============================================